home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950726-19950929 / 000404_news@columbia.edu_Wed Sep 20 11:01:40 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA18861
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Thu, 21 Sep 1995 05:49:40 -0400
  3. Received: by apakabar.cc.columbia.edu id AA23054
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Thu, 21 Sep 1995 05:49:39 -0400
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!news.uoregon.edu!gatech!news.mathworks.com!tank.news.pipex.net!pipex!howland.reston.ans.net!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Progress on MSK 3.14 and Linux 1.2.8 problem
  9. Message-Id: <1995Sep20.170141.61741@cc.usu.edu>
  10. Date: 20 Sep 95 17:01:40 MDT
  11. References: <43c0ds$hvk@apakabar.cc.columbia.edu> <2994@sun3.IPSWITCH.COM>
  12. Organization: Utah State University
  13. Lines: 21
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <2994@sun3.IPSWITCH.COM>, ddl@harvard.edu (Dan Lanciani) writes:
  17. > In article <1995Sep19.092901.61603@cc.usu.edu>, jrd@cc.usu.edu (Joe Doupnik) writes:
  18. > 
  19. > |     So far I would conclude that your version of Linux has problems
  20. > | in its TCP/IP stack. And that the problems are sensitive to whether or
  21. > | not an ARP reply has the IP address of the requestor or 0.0.0.0 there
  22. > | (current MSK has the IP address, previous v3.14 did not by mistake).
  23. > |     Anyone else have some ideas? Dan?
  24. > 
  25. > Ah, well, that certainly explains it (assuming the version that sends
  26. > 0.0.0.0 is the one we were talking about).  Glancing at the Linux code
  27. > I see that it will drop any replies that aren't addressed (meaning that
  28. > target ip is one of its addresses) to it.  This action appears to be
  29. > intentional.  Of course, this doesn't explain why the fixed kermit fails
  30. > in a worse way...  Perhaps some other field is getting trashed?  The Linux
  31. > code seems to be quite picky and checks all the length and type fields.  If
  32. > anything is wrong, the ARP packet gets dropped.
  33. ---------
  34.     It doesn't explain it at this time since the data are missing. A
  35. quick packet trace would be a good start on the data part.
  36.     Joe D.